The growth and competition in the casino gaming market in recent years and the increasingly sophisticated and complex technology being integrated into the gaming environment, at the individual game, casino management, and auditing levels, presents both challenges and opportunities to game manufacturers, gaming establishment operators, and regulatory agencies. The technological capabilities and requirements of, for example, advanced electronic games, multi-site gaming operations, detailed player tracking, wide area progressive jackpots, and various alternatives to the use of currency and coins by players, all present a potentially huge pool of ever-changing data which can be of great value to casino operators (from a management standpoint) and to regulators from an audit/compliance standpoint.
In recent years, the popularity of video EGMs such as video and video poker EGMs has increased dramatically. Such EGMs are provided by a number of manufacturers. The growth of these types of EGMs has presented numerous opportunities to provide new and automatic services in the various areas, such as, EGM accounting, EGM monitoring, EGM progressives awards/jackpots, EGM ticketing, player tracking, player bonusing have been realized. Such services generally require information, e.g., meter information, taken directly from the electronic EGMs. This information is usually gathered and/or relayed to central/remote locations through specialized/add-on devices. These devices must communicate to the EGM using a communications protocol over a communications link which is typically dictated by the type and/or manufacturer of the EGM. It should also be noted that the communications link and/or architecture used for all EGMs at a particular site, e.g., is not necessarily the same.
One common communication protocol used to communication with electronic EGMs is the Slot Account System or (SAS) protocol. With particular reference to FIG. 3, a typical SAS implementation is shown. In this illustration, the EGMs 302, 304 are provided with corresponding slot machine interface board (SMIB) devices 306, 307 and player tracking devices 308, 309. The SMIB devices 306, 307 are physically connected to, and located within, the respective EGMs 302, 304. The player tracking devices 308, 309 are connected and communicate to the SMIBs 306,307 through either RS-232 or USB 312.
EGM accounting and monitoring data is exchanged to and from each EGM 302, 304 via the SAS protocol over respective communication links 310 to the SMIBs 306, 307 which is then communicated through RS-232 or Ethernet over respective communication links 318 to the Bank Controller 314 which communicates to the EGM Accounting & Monitoring server(s) 316.
Player tracking data is exchanged to and from the SMIBs 306, 307 then communicated over RS-232 or Ethernet over respective communications links 318 to the Bank Controller 314 which communicates to the player tracking server(s) 320.
Generally, these types of SMIBs are data pass-through or polled devices and contain little intelligence. In other words, the devices 306, 307 simply pass data back and forth between the EGMs 302, 304 and a bank controller 314 over respective second communication links 312, 318 using the SAS protocol. In most cases, the bank controller 314 contains the majority of the gaming logic and simply polls the SMIBs 306, 307 for data. The second communication links 318 may be implemented over an RS-232 or Ethernet. The bank controller 314 then relays the data back to the EGM Accounting and Monitoring server(s) 316. The player tracking devices 308, 309 interfaces with the SMIB and Player tracking server(s) 320 for player tracking related data and simply passes EGM specific data back and forth between the SMIBs 306, 307 through communication link 310 and player tracking specific data back and forth between the player tracking server(s) 320 by way of the bank controller 314.
Typically, a casino includes numerous EGMs arranged in banks. Each bank of machines has a corresponding bank controller 314 which is located remotely. One problem with this type of arrangement is that all of the EGMs 302, 304 which are connected to one bank controller 314 must use the same communications protocol. This, for example, all EGMs 302, 304 connected to the bank control 314 must utilize the SAS protocol.
The trend in gaming is to require more and more EGM and player tracking data to and from the EGMs 302, 304 and/or the SMIB devices 306, 307 and player tracking devices, 308 and 309. For example, one trend if the gaming industry is to move towards downloadable games, i.e., game software, including new games, updates, etc. . . . , which is downloaded from a central server to the EGMs. Another trend is to provide live and/or streaming video or other multimedia content either directly to the EGMs or the player tracking device.
Historically utilized communication protocols, e.g., SAS, X-Series, and QCOM were not designed to handle this type or volume of data such as downloading a new game to the EGM. The Gaming Standards Association has recently released a new standardized communications protocol, the Game-to-System or G2S standard, which was designed to provide a standard communications protocol which can handle the amount and type of data required by these new applications or services. The G2S operates over an Ethernet communications link using the TCP/IP protocol. However, the G2S protocol requires data to be transmitted in an XML format.
One potential hardware architecture to implement the G2S standard is shown in FIG. 4. This architecture shows that the SMIB device 307 from FIG. 3 are removed and the EGMs 304 communications is protocol 310 is replaced with Ethernet 311. Services provided using G2S are administered using G2S servers 322. The G2S server(s) 322 communicate to the player tracking server(s) 320 through the GSA System to System (S2S) protocol to each G2S player tracking device 308 through a data link over an Ethernet network 313. For player tracking services, a separate Ethernet links between the player tracking server(s) 320 and each G2S player tracking device 308. The G2S servers 322 and the player tracking server(s) 320 are also located at a remote location. Thus, separate Ethernet links must be provided to each G2S EGM 304 (and/or G2S player tracking devices 308). As each implementation, e.g., casino, can include thousands of EGMs, the amount of connections and network cabling using such architecture is immense and costly not to mention the complexity of network administration. Another problem is that most implementations, e.g., casinos, will for the foreseeable future be a hybrid of SAS and G2S EGMs and must accommodate both SAS protocol EGMs as illustrated in FIG. 4. There are significant complexities involved in support both SAS and G2S architectures simultaneously.
Another problem is that the G2S protocol, in using an XML format is not an efficient way to communicate large amounts of response sensitive data in real-time. One potential problem is that even high speed Ethernet networks may not be able to support the bandwidth required in providing such services using the G2S protocol to G2S EGMs 304.
Another problem is that in the systems shown in FIG. 3 (and systems using similar architectures), in order to move a EGM (or other EGM) from one location, e.g., from one bank of machines to another bank of EGMs, both the old bank controller, i.e., corresponding to the bank of machines to which the machine being moved used to belong, and the new bank controller, i.e., corresponding to the bank of EGMs to which the EGM is being moved, must be reprogrammed to, respectively, remove the EGM from the old bank of EGMs and to identify the EGM in the new bank.
The present invention is aimed at one or more of the problems as set forth above.